During ordinary operation of computer networks it is usual for a client to access a server and to request access to a resource provided by that server. A client may be thought of as a program running on a work station, desktop type computer, personal digital assistant (PDA) or even an embedded device, and a server may be thought of as a program performing a service for a plurality of clients. The client may also be thought of as the computer running the client software, and the server may also be thought of as the computer running the server software. For some purposes, the client may be thought of as a user on whose behalf a request is being made. In some cases, the same computer may run both the client software and the server software. The service is ordinarily provided by the execution of a server program at the request of the client. Specifically, the service provides a resource to the client. The resource may be any operation that is executed, affected or controlled by a computer, such as a word processing or spread-sheet program, the transfer of files, or some other data processing function. The resource access may also include the ability to read or to modify entries in a database, execute or modify a program maintained by the server, or even modify data maintained by another computer in the system.
In deciding whether or not to grant access to a resource, a resource server must answer two questions:                A. “Is the client correctly identifying himself?” and        B. “Is the identified client authorized to access the requested resource?”The first question involves a process called “client authentication.” The second involves reference to an authorization decision mechanism, such as an Access Control List (ACL) maintained by the server and containing a list of individual clients and/or client groups who are permitted access to the resource.        
Client authentication can be accomplished using public key cryptographic methods, as described in Network Security, Private Communication in a Public World, Charlie Kaufman, Radia J. Perlman, and Mike Speciner, PTR Prentice Hall, Englewood Cliffs, N.J., 1995, (Kaufman et al.) at chapters 5, and 7 and 8, pages 129–161 and 177–222. Specifically, client Alice can authenticate herself to resource server Bob if she knows her private key and Bob knows Alice's public key. Bob has obtained Alice's public key in an identity certificate from a trusted certification authority or from a certification authority in a chain extending from a trusted authority. Other methods of authentication may be used and the present invention does not depend on which method is used.
An identity certificate may be revoked. One common method of dealing with revocation involves the use of Certificate Revocation Lists (CRLs) which are analogous to the books of revoked credit card numbers that were at one time published and distributed periodically to merchants. Like these books, CRLs suffer from being expensive to distribute and are therefore infrequently distributed. There may also be a significant period of time between certificate revocation and CRL distribution, during which the resource server is unaware of the revocation.
For maximum security, the certificate authority may be off-line and therefore inaccessible on a transaction-by-transaction basis. Moreover, issuance of an identity certificate may be a relatively lengthy process so that, even if the certificate authority is online, it is impractical to issue an up-to-date certificate for each transaction. An alternative approach to certificate revocation involves the use of on-line revocation servers, which maintain lists of revoked identity certificates. With on-line revocation servers, up-to-date revocation status can be determined.
At the same time, if a revocation server's private key has been compromised, the damage will be more limited than if an on-line certification authority's private key were compromised. Specifically, if the certification authority's private key were compromised, the authority might issue new certificates to unauthorized clients. On the other hand, a compromised revocation server would result only in continued access by a client with revoked authorization. Specifically, a compromised revocation server can never grant unauthorized access to a client who has never had authorized access. Although a compromised revocation server may wrongly revoke an authorized client, the revocation would only be a denial-of-service attack.
The use of on-line revocation servers, which is analogous to the method employed today for the authorization of credit card purchases, is also expensive because the resource server usually contacts an on-line revocation server at each transaction to determine whether the certificate has been revoked. The OCSP (On-line Certificate Status Protocol) proposed standard of the PKIX working group (RFC 2560) at <ftp://ftp.isi.edu/in-notes/rfc2560.txt>, specifies that the revocation status for each certificate can be retrieved from the revocation server and cached by the resource server verifying that certificate. Although caching improves resource server efficiency, it still places a burden on the resource server, which may already be burdened with the processing of resource access requests.
An authentication and authorization arrangement introduced by the Open Software Foundation (OSF) and known as the Distributed Computing Environment (DCE) model has a central database on a machine known as a “privilege server” or “central trusted authority.” When a client logs on to the system, the privilege server issues a secret, or symmetric, key certificate (as opposed to a public, or asymmetric, key certificate) identifying all the groups of which the client is a member. The client presents this certificate to any server on which the client wishes to access a resource. The resource server has an ACL for the resource, and the ACL includes both authorized clients and client groups. If neither the client nor any one of the groups of which the client is a member is listed in the ACL, client access is denied. This approach saves some work for the server, but requires that a central trusted authority know all the groups of which the client is a member and also that the client's group list is small enough so that presentation of the entire collection is not unwieldy. The DCE model is described in Kaufman et al. at Section 17.7, pages 455–459.
When a client wishes to access a resource on a server, at least one of them needs to gather and maintain various credentials for client identification and authorization. These credentials may include public key identity credentials, group membership credentials, group non-membership credentials and non-revocation credentials. In some cases, the client gathers the various credentials and submits them to the server for access to the resource. However, for the client, such task may be time consuming and particularly burdensome in situations where the gathering occurs at the time of access. The client may therefore cache the credentials for future use. However, the server may have various constraints on the credentials it will accept, such as recency requirements. If the server refuses to accept “stale” credentials, the client may have to re-gather the credentials, thereby delaying the access. In other cases, the server does the work of gathering the various credentials to determine whether a client is authorized to access the resources. If the server gathers the various credentials at the time of client access, this may cause an undesirable delay to the client. The server may also cache the various credentials. However, if the cached credentials do not meet the server's recency requirements, it will have to re-gather the credentials, thereby delaying the access. This problem is not limited to the client-server situation; it exists whenever an entity needs to gather credentials and keep them up to date.